Modern computerized systems are increasingly reliant on automatic programs labeled as “bots” to access systems remotely. These programs are quickly becoming more capable, complex, and useful, and as such get to handle more important tasks and with higher value. In the consumer banking sector, the Payment Services Directive (PSD1) effective from 2009 in the European Union required banks (in this context named ASPSPs, Account Servicing Payment Service Providers) to share user transaction and account information with Third Party Providers (TPPs) that were registered as Payment Service Providers if the end costumer approved the TPP to do so. The regulation gave rise to the so called “FinTech” (financial technology) companies which provided new services and innovative thinking to the financial sector. A shortcoming of PSD1 was that there was no specification on which way the ASPSPs were supposed to provide the information, so the method the FinTech companies typically chose to access the account information was by bots that collect the information from the banks web site via so called screen-scraping (also termed web scraping, data scraping etc.) Screen-scraping means that the TPP uses a bot to browse the web site, enter the customers login credentials to access the account, and view/download the information, not unlike the way a human acquires the information. However, the specific way the bot works needs to be programmed by the TPP for each individual service requested and for different ASPSPs, since their web sites differ.
In the PSD2, effective from 2018, further TPP agents were introduced (Account Information Service Providers and Payment Initiation Service Provider). This enabled FinTech companies to access even more banking data and develop applications that mediate payment services, visualize account information across all the customer's banks, track and analyze household spending habits and so on. The PSD2 proposed a formulation that forbids the use of screen-scraping for payment accounts (not the other types) without the TPPs identifying themselves first. The use of this technique has been wildly debated for several years, where ASPSPs want to force all TPPs to access the banks via Application Programming Interfaces (API) instead, which would increase security but also put the ASPSPs in full control of the data shared. Critics proclaim this will stifle innovation and hamper the FinTech industry. The open banking concept, and indeed the UK namesake, Open Banking Limited, are alternatives developed for open source code-based API access to mitigate the problems of screen scraping. In the UK, this will come into effect in September 2019, but the rest of the EU have not agreed on such a date. With this, new possibilities for strong customer authentication (SCA) have been proposed by the European Banking Association (EBA).
However, the TPPs stand by and defend screen-scraping despite the obvious drawbacks and prefer to use it for several reasons. It relies on the well-established and quite legal activity of machine-reading web sites, which is omni-present in many areas of the Internet. The FinTech industry has used this technology for over 15 years without a single reported data leakage where credentials were compromised. The industry further “argues” that closed source code operating systems (such as Windows and Mac OS) and browsers (Firefox, Chrome, IE, Safari) must anyway be used for accessing the ASPSPs services, which is potentially less secure and transparent than the open standards used by the TPPs. Regardless of the future developments in the legal framework, screen-scraping will continue to be prevalent for many ASPSPs for years to come.
Another area where bots are frequently used for high-value tasks are the complex industrial and other networks that constitute command and control, process regulation, grid steering and other large-scale systems critical to infrastructure, public well-being, and the connected and intelligent factory technologies going under the umbrella name of “Industry 4.0.” Typical applications where bots are used are to perform maintenance, surveillance, and measurements, since the use of them is often much more cost-effective than trying to implement such as with an API in legacy systems.
With the widespread practice of screen-scraping, the ASPSPs lose all control of who is connecting to the account. The customer credentials must be stored at the TPP, and the process results in human customers becoming familiar with and accepted passing their authentication credentials to other entities which is a weak security practice. In addition, the human customer often grants access to their information indefinitely and may even forget which TPPs they have shared the information with, meaning credentials that were originally intended to be only known by a single person risk being stored in several different locations, at companies that can be bought and sold in several iterations.
It is easy to see that a data leak from a TPP could have disastrous consequences. Should login credentials leak from a TPP, customers' accounts could be accessed and used fraudulently in large numbers. One major problem when it comes to protect against stolen credentials is that the fraudulent use stemming from a leak will be hard to discern from the legitimate use of the screen-scraping bots used by the TPPs, and even under the new PSD2 legislature, a fraudulent actor would only need to provide the ASPSP with the identifier of the TPP. The ASPSP must then grant the access, as required by the regulations.
Also, in the case where the TPP communicates with APIs to the ASPSP there still exists a possibility that a fraudulent actor can misuse such data. An application that mediates API calls, i.e. by automatic scripting or manual access, could be used with stolen credentials to gain unauthorized access.
In a utility network, the bot login credentials might not even be kept under encryption or obfuscation, as the humans supervising the bot operations are typically considered benign and authorized users by themselves. However, an unauthorized access by a human using the bot credentials could still have severe consequences, by mistake or intent, and therefore the system operators in many cases want to be certain these credentials are not used by human operators.
In all cases above, there is no reasonably known way to a skilled person of making sure, in the prior art, that the entity seeking access is either the bot doing the TPP's work, or the bot performing the wanted utility tasks. No known mechanism exists at the accessed ASPSP's network to ensure the bot is the one used by the TPP granted authentication, or at the utility network's accessed device, machine, or plant, to safeguard against human missteps caused by access given to humans through faulty credentials. Bots are not, typically, equipped with mechanisms to handle two factor or hardened cryptographic tokens and obviously they are not suitable for biometric authentication, such as fingerprints, facial recognition or iris scanning. These limitations force a system designed to provide access with credentials that are easy to clone or copy.
Thus, what is needed is a way of ensuring that access is being granted only to a bot which should have access to a user account or financial information, even if the bot has the proper user authentication credentials.